IBIS Macromodel Task Group Meeting date: 15 December 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Ken Willis * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Rui Yang Luminous Computing * David Banas Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the meeting would be the last of the year, and meetings normally scheduled for December 22nd and December 29th are cancelled. Arpad thanked everyone for their efforts in 2020. ------------- Review of ARs: - Arpad to ask Steve Parker to post Alaeddin's presentation to the ATM archives. - Done. Arpad said he had sent the request, but the document was not yet posted. Arpad noted that the original slides had not been sent to the ATM list, and Alaeddin had sent out revised slides based on feedback from Curtis. Arpad asked Curtis to summarize the issue. Curtis said Alaeddin's presentation had proposed new Reserved Parameters allowing the model maker to specify whether the Redriver Tx took the PRE (upstream) or POST (downstream) IR information or BOTH as an input. In slides illustrating the flow of IR processing in the PRE and BOTH cases, the upstream IR information had been double counted because the upstream IR was explicitly convolved into the input to the final Rx even though it was already contained in the output of the redriver Tx. Curtis noted that Alaeddin had provided an update/errata on slide 2 of the revised presentation. Arpad said that to avoid spreading the original mistake, he had sent the revised version to Steve and asked him to post it to the archives instead of the version that was presented in the meeting. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the December 8th meeting. Randy moved to approve the minutes. Jared seconded the motion. There were no objections. ------------- New Discussion: Clock Forwarding BIRD (BIRD204) issue: Walter shared his recent email regarding a problematic scenario. If the Data (e.g., DQ) model has Rx_Use_Clock_Input set to "Times", and the Clock model (e.g., DQS) does not return clock ticks, what should we do? Walter suggested that we should require the DQS model to have a GetWave function and to return clock ticks if the DQ model wants clock ticks as an input. Walter noted that we do not have a Reserved parameter that indicates whether a GetWave function does or does not return clock ticks. So, we should mandate that the DQS model corresponding to a DQ that wants "Times" must return clock ticks. Also, we should not allow such a DQS model to be Init-Only. Walter said that if the DQ model wants "Wave" as an input, then the existing language in the BIRD is fine. The existing language stating what the EDA tool should do if the DQS model has no GetWave is sufficient. However, for the "Times" case, he suggested adding a new sentence: For the "Time" option, the Clock shall have a DLL with an AMI_GetWave that returns clock_times. Ambrish said he agreed with Walter, and that it would be ironic if the Clock model didn't return clock times ;-). Walter summarized: If the DQ model wants "Times" (clock ticks), the DQS model that goes with that DQ should have a GetWave function, and it should return clock_times. Otherwise, we're asking the EDA tool to create the clock_times. Ambrish said the EDA tool already has to generate the clock times in the case of Init-Only models in general. Walter said each EDA tool has its own way to generate a clock, but that may not agree with how the DQS would generate the clock. Fangyi agreed with Walter and also agreed with his suggestions. Walter said that if the model maker is sophisticated enough to create a DQ model that takes the clock_times as an input, then they can create a DQS model that returns clock ticks in the clock_times argument. Fangyi mentioned one other combination. What if two DQ models utilize the same DQS, and one has Rx_Use_Clock_Input set to "Times", and the other has it set to "Wave"? Walter said it was an odd combination, but as long as the DQS model returned clock_times the EDA tool would know what to do for each DQ. Arpad noted that BIRD204 had already been approved, and any proposed addition to the language of BIRD204 would require us to create a superseding BIRD. DC_Offset clarification: Hansel discussed an issue with BIRD197.7's interaction with the PAM4 threshold parameters and Rx_Receiver_Sensitivity, which he thought might require clarification. He noted that BIRD197.7 says the EDA tool "may" use the value of DC_Offset to post process data returned by the model. Hansel suggested a model maker doing single-ended PAM4 might not know whether the threshold values should include the DC_Offset or not. Do we need to add a line stating that the EDA tool utilizes the Rx_Receiver_Sensitivity and PAM4 thresholds prior to applying the DC_Offset? Randy said if the EDA tool is using the DC_Offset then it may need to adjust these parameters, too. Ambrish said these parameters are always to be applied to the waveform returned by the model without the DC_Offset. He noted that BIRD197.7 makes it clear the EDA tool may utilize DC_Offset for "post processing". Hansel agreed, but he said the specification could be clearer. Fangyi said there is no issue of ambiguity with Rx_Receiver_Sensitivity, since it is applied relative to whatever thresholds are decided. That leaves the PAM4 thresholds, and Fangyi agreed with Ambrish that they do not contain the DC_Offset. Fangyi also noted that BIRD197.7 says the tool may use DC_Offset for post processing and display. Randy said that if he were developing a GDDR6x model he wouldn't know what PAM4 thresholds to use, as those have to be trained. Fangyi noted that the model can return new values for them with each and every GetWave call, so they can move around. Ambrish said that the EDA tool can also compute them, and he recalled that he'd introduced a topic a few weeks ago about the fact that the PAM Upper and Lower thresholds are required according to the current specification (the PAM4 Center can be left unspecified and the assumed default is 0V). He plans to write a BIRD to remove the requirement that PAM4 Upper and Lower threshold values be returned by the model. Fangyi agreed with the gist of Hansel's clarification question. He said in a real device the DC_Offset is gone after the comparator, and the device is working with a differential signal. The model maker should be thinking of the differential signal, and the threshold values should not include the DC_Offset. Randy said the system has to train the 3 Vref levels used by a single-ended PAM4 receiver, which makes it a bit more difficult for the model. Arpad asked if we had consensus that Hansel's suggestion was useful and that he should create a BIRD. Curtis said we seem to have consensus on what the intent was, and he suggested the first sentence of Usage Rules: for the PAM4 threshold parameters might be the place to make Hansel's clarification. The sentence ends: "...when the signal is sampled:" Curtis suggested the definition of signal could be clarified. Fangyi agreed and said the intent was that "signal" meant the waveform returned by the Rx GetWave, which has no DC_Offset. No one disagreed, and Hansel took an AR to draft a BIRD to clarify the language. Hansel asked Randy if the hardware would ever train the DC_Offset itself and if it would be useful to have this parameter as an InOut instead of just an In. Randy said there's a difference between DC_Offset, which is based on the driver termination choices that set a particular DC level, versus training the Vref(s), which represents the sampling voltage(s) and can be trained by the Rx. Hansel said his question came from an NRZ example he'd been playing with, and he said that he'd seen an issue with pre-emphasis in his Tx knocking down the DC level. He asked if this was expected and if we had to worry about the DC_Offset value being changed by the Tx. Fangyi said this question had come up in previous discussions, and that in the physical system pre-emphasis should not affect the DC offset. Hansel said he hadn't fully sorted his experiments yet, and it was likely he just had a signal processing issue. Redriver Flow Issues: Arpad summarized the issues we had been discussing and reiterated his request that we come up with some way to address the issues. He said we have identified certain combinations of Init-Only, GetWave-Only and Dual models that are difficult or impossible to support. We had spelled out some rules during the discussion, for example, having an Init-Only model appear downstream of a model with GetWave can be problematic. Arpad asked if Alaeddin's proposal would be free of these problems, and if not, how do we address them? Fangyi and Curtis said their impression was that Alaeddin's proposal did not solve the issues with troublesome combinations. Arpad said the bottom line is we have to find a way to address these combinations. Are we okay with spelling out situations where model types will work together flawlessly and saying, "use at your own risk" otherwise? Alternatively, do we have to find a solution that supports everything? Arpad noted that some people prefer Init-Only and GetWave-Only models or at least think it's very important to support them. Others prefer Dual models. With those two competing views, he wasn't sure we had a solution. Fangyi agreed that before we try to resolve flow issues, we should decide what combinations we support. Michael asked if we needed more specific BIRD language from Alaeddin as opposed to his proposal presentations. He said from their perspective Alaeddin's proposals introduced some needed clarifications and some potential new parameters, even if they did not address all of the troublesome combinations. Arpad said he wasn't yet sure exactly what changes Alaeddin was proposing. Arpad noted that Ambrish had drawn an interesting distinction in an earlier meeting. He had said that Dual models were part of the flow in the sense that such models could support the statistical and time domain flows. However, the original flow discussions did not anticipate GetWave being dependent on what was passed into Init. Arpad asked if eliminating that situation would reduce the number of problem cases. Michael asked if "Dual" model implied that the Init and GetWave are entirely independent. Arpad said Dual does not imply any dependence between Init and GetWave. Dual model means that the same EQ functionality is implemented in both the Init and GetWave functions so that the EDA tool could perform the AMI analysis in statistical or in bit-by-bit (time domain) mode. Ambrish agreed a Dual model is one that supports both statistical and time domain flows using one model. He reiterated his concern that the original intent was not to have the GetWave function's results have any dependence on what was passed to Init. David asked if Init_Returns_Impulse is the way we differentiate between the two cases (i.e., if Init_Returns_Impulse is true, then the model returns a modified IR and supports statistical flow). Michael said that he's focused on whether the model supports the statistical flow, and deducing that from Init_Returns_Impulse seems cumbersome. He said he'd prefer a parameter like Model_Supports_Statistical_Flow, but he understood David's point. Michael reiterated that his group wants models that support the statistical flow if at all possible. They like to use DOE with statistical mode models. Walter said that as an EDA vendor, if we see a model with Init_Returns_Impulse true, then we assume the output of the Init function can be used for statistical flow. If that model also provides a GetWave, then it means that statistical may capture a lot, but to be more precise one needs to use the GetWave functionality as well. We have to balance good use of statistical with its limitations vs. using GetWave where you're likely limited to simulating to 1e-5 or 1e-6 BER. He said the assumption is that the Init output IR includes all of the equalization, and the GetWave output includes all of the equalization. Walter said a third thing that Init can do is adaptive equalization for things like CTLE, which it can provide to GetWave even if it doesn't return an IR. David asked how the info gets communicated between Init and GetWave. Walter said it's done internally within the model. The Init function may adapt the CTLE based on its input IR, and then the GetWave uses the CTLE settings and may do further optimization itself. Ambrish said this behavior represents a design decision by the model maker and is independent of EDA tools. Walter summarized and stated that there are 3 possible functions of Init: - memory allocation and setup - output a modified IR (Init_Returns_Impulse is true) - Internally pass information to the GetWave function. Walter summarized his position on the flow issues: - We need a corrected flow. - GetWave flows are fine, and the input to every GetWave is the cumulative upstream waveform. - We need to change the Init flow to focus on the upstream information as well. We should never pass a downstream IR to an Init function. This is already true for Rx models, but we should change Tx models to this upstream flow as well. - Walter said almost every Tx model he had ever encountered could work fine in a new upstream mode. The only Tx model he'd ever seen that optimized itself was never used in that mode because its optimization didn't work well. Ambrish said we'll have to solve this next year. Arpad thanked everyone for joining and for their work in 2020. AR: Steve Parker to post Alaeddin's presentation to the ATM archives. ------------- Next meeting: 05 January 2021 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives